瀑布真正的產品是承諾：多少錢、多久、交出什麼。甘特圖只是這個承諾的投影。

一張很漂亮的甘特圖

昨天說過，很多自稱敏捷的團隊，其實連瀑布都沒做好。要理解這句話，得先搞清楚瀑布到底在做什麼。所以今天先講一個「看起來很瀑布」的故事。案例一樣經過去識別化與合併改寫。

某個專案型計畫，合約簽了，交期十個月，金額固定。開工第一週，上面交代的第一件事不是釐清需求，而是：

「先給我一版甘特圖，查核會議要用。」

於是團隊花了三天，生出一張很漂亮的甘特圖：分析、設計、開發、測試、驗收，五條大 bar 首尾相接，里程碑用菱形標好，列印出來剛好一頁 A3。

期中查核，委員看著圖問進度。PM 回答：「設計階段完成 100%，開發完成 60%。」全綠，過關。

會後，一位比較資淺的成員小聲問了一句：

「設計完成 100% 的意思是，我們知道要做什麼了嗎？」

資深工程師笑了一下，沒有回答。因為他知道實際狀況：所謂「設計完成」，是設計文件的頁數寫滿了；而系統真正要介接哪幾個外部系統、資料要從誰家來、驗收時委員會看什麼——這些問題有一半還沒有答案，另一半的答案在他腦袋裡。

專案後期的發展，做過的人都能背：開發進度在 90% 停了很久；測試期被壓縮成原本的三分之一；驗收前一個月，大家才發現客戶想像的東西跟做出來的不一樣；最後靠加班、追加人力與「先驗收再補」把案子收掉。

事後檢討，結論是：

「瀑布就是這樣，不切實際。我們應該敏捷一點。」

等一下。這個專案，真的跑過瀑布嗎？

當時團隊怎麼理解瀑布

當時團隊對瀑布的理解大概是：依序的階段、大量的文件、一張甘特圖、幾次里程碑查核。我們照著做了——圖畫了、文件寫了、查核也過了——所以我們在跑瀑布。

炸掉之後，自然得到「瀑布沒用」的結論。

但把瀑布理解成「甘特圖加文件」，就跟把敏捷理解成「Standup 加看板」一樣：只學到外觀，沒買到產品。昨天那個團隊買了敏捷的儀式，這個團隊買了瀑布的儀式，兩邊付的都是全票。

瀑布到底在賣什麼

瀑布（Waterfall／Predictive）真正的產品只有一個：

可預測的承諾。

它讓一個組織可以在動工之前回答三個問題：

要花多少錢？
要花多久？
最後會拿到什麼？

這三個答案能簽進合約、編進預算、排進其他部門的計畫。這就是瀑布的賣點，也是合約案、標案、跨組織專案至今仍大量使用它的原因：因為買方要買的就是承諾。

而要能給出這個承諾，瀑布背後有一條完整的邏輯鏈：

我們認為已經知道得夠多
        ↓
把「要做什麼」寫下來，凍結成 Baseline
        ↓
根據 Baseline 估算 Cost / Schedule
        ↓
照承諾執行
        ↓
有人要改？走 Change：重新估算、重新承諾
        ↓
交付時，拿 Baseline 加上 Change 的總和來驗收

注意兩件事。

第一，這條鏈的第一行是一個前提，不是一個步驟。瀑布沒有魔法讓你知道得夠多，它只是假設你已經知道了。前提成立，後面全順；前提不成立，後面每一步都是在對一個猜測做出精確承諾。

第二，甘特圖在這條鏈的哪裡？在第三步之後——它只是估算結果的視覺化。Baseline 才是本體，甘特圖是投影。

拿著這條鏈回頭看開場的故事，會發現每一環都是斷的：

合約先簽、交期先訂
→ 承諾發生在估算之前，順序整個顛倒

「設計完成 100%」
→ 完成的定義是文件頁數，不是問題被回答

需求邊做邊變，大家用口頭吸收
→ Change 沒有走，承諾從未重新計算

驗收前一個月才對齊期待
→ 驗收依據從頭到尾不存在

這不是瀑布失敗。這是根本沒有跑瀑布，只演了它的儀式——跟 Day 01 那個「有 Sprint 沒敏捷」的團隊，是同一種病的兩種症狀。

順帶一提，連最常被叫做「瀑布之父」的那篇文章——Royce 在 1970 年發表的 Managing the Development of Large Software Systems——在畫出那張著名的階段圖之後，緊接著就寫了這樣做「有風險、容易失敗」（risky and invites failure），並主張加上迭代與提前驗證。單趟直落、絕不回頭的瀑布，從第一天起就是個被作者本人警告過的簡化版。這裡點到為止，本系列不打算考古；重點只有一件事：瀑布的本體是承諾與變更管理，從來不是那張圖。

大神腦袋裡藏了什麼

那這個專案是怎麼撐到結案的？

靠那位笑而不答的資深工程師。

甘特圖照畫、查核照過，而真正的專案狀態，由他在腦中維護：

真正的 Scope
→ 圖上寫「系統開發」，他知道實際要介接哪幾個外部系統

真正的估算
→ 他心裡有一版真實時程，知道哪些 bar 是畫給委員看的

真正的變更史
→ 客戶每次口頭改需求，他記得，並默默調整做法

真正的驗收標準
→ 他知道委員到時候會問什麼、想看什麼

換句話說，Baseline、Estimation、Change Record、Acceptance Criteria——瀑布邏輯鏈上的每一個 Artifact 其實都存在，一個都沒少。只是全部存在一個人腦中，而且不對外發布。

於是組織看到的是「瀑布的文件都做了，還是炸」，得到「瀑布沒用」的結論。實際上是：紙上那套瀑布是假的，真的那套在大神腦裡，而一個人的頻寬，撐不起整個專案的承諾。

這次到底誰在吸收代價？

老規矩，做一次檢查。合約簽死，所以 Scope 不能少；交期寫在合約上，所以 Time 不能延；預算固定，追加的那點人力杯水車薪。那「承諾跟現實的落差」這個代價，最後記在誰的帳上？

Scope       □   合約列的一項都沒少
Time        □   交期如期「達成」
Cost        □   小幅追加，遠小於實際缺口
Quality     ■   測試壓成三分之一、先驗收再補
Risk        □   沒有人重新評估過
人          ■   大神的記憶、全隊的加班   ← 還是這格

跟 Day 01 不同的是，這次多勾了一格 Quality。這其實是常態：當人吸收不完的時候，溢出的部分會流進品質——只是品質的帳單比較晚寄到，寄到的時候通常寫著「維護成本」四個字。

當 Scope、Time、Cost 全都簽死的時候，Quality 跟人就是僅剩的兩個緩衝。

如果沒有大神，應該留下什麼

回到瀑布的賣點：承諾。一個健康的承諾，最小需要哪些東西才能離開大神的腦袋？

不是一份兩百頁的規格書。是在答應任何交期之前，團隊能一起寫出這四行：

1. 我們答應交付什麼？
   （列得出具體項目，不是「如合約所示」）

2. 這個承諾建立在哪些假設上？
   （哪些事情我們其實還不知道）

3. 每一項怎樣算驗收通過？
   （誰來驗、拿什麼驗）

4. 上面任何一項變了，承諾要怎麼被重新計算？
   （改變的代價由誰決定、記在哪裡）

寫不出來也還是可以開工——大部分專案都是這樣開工的。差別在於：寫得出來，承諾是團隊的；寫不出來，承諾遲早變成某個人的。

今日 Artifact｜最小承諾記錄

把上面四行收成今天的 Artifact，貼在任何你即將答應別人的東西旁邊：

□ 交付項目：我們答應交出＿＿＿＿
□ 假設清單：這個估算假設了＿＿＿＿還沒被推翻
□ 驗收依據：由＿＿＿＿用＿＿＿＿判定通過
□ 變更出口：以上任何一項改變時，走＿＿＿＿重新承諾

四格都填得出來，你手上那張甘特圖才有資格叫做計畫；填不出來，它只是一張畫得很整齊的願望清單。

今日一句

甘特圖不是承諾，它只是承諾的投影；沒有 Baseline 的甘特圖，是對著一個猜測畫出的精確時間表。

瀑布賣的是承諾，前提是「我們已經知道得夠多」。那如果我們誠實承認：現在就是不知道呢？

明天換另一邊：敏捷到底在賣什麼？提示——答案也不是 Sprint。